I have been successful at loading Tweakie's script for auto tool height setting; and also turned it into a macro so it can be called from within a program.  Turning it into a macro was easy, I just copied the button script and saved it as "M900.m1s" in the macro folder.  

However, I have now hit a strange problem which I wonder if anyone can help with?

I have added a feature to the macro that inserts an extra probing pass.  So, first it lowers the tool at a reasonably high speed (100mm/min for example) until the probe triggers; then raises the tool by .25mm; then lowers it at a slow speed (20mm/min) until it again triggers.  This I did because I found, as have others, that the accuracy of setting seems to depend on speed, presumably because of delays between the probe signal being asserted and the software actually seeing it.  This works very well as a macro, being quicker to reach a more accurate setting from a higher starting position which is desirable if you are changing a tool.

However, copying the modified macro back into the button script doesn't work!  When I press the button, the tool lowers to the probe as before, but when it reaches it it stops, then after a few seconds starts to randomly and very slightly "jiggle" up and down, whilst the following message appears in the status window:

"Probe Ignore, activated at call for probe"

I'm baffled, can anyone help please?

A subsidiary question: having written a macro, is it not possible to just call it from within the button script?  It isn't obvious why not, since for example the original script contained various calls to built-in macros (for spindle stop for example).

TIA,

John.

Looks like you did NOT raise the probe UP enough for the switch to recycle closed. The message is telling you that the probe is still active(switch open).

As to a macro calling another macro , sure you can BUT there is no guarantee as to how it will react or IF it will all stay in sync.  The Mcodes are internal Macros and may be handled differently.

Just a thought, (;-) TP

Thanks TP, I wondered about that and will give it a try.  But it doesn't explain why the macro that works when you call it as a macro doesn't work when it's a button script!

There have been some problems with later versions and button calls . You may want to back up and try and earlier version.

Post your button code that does not work and I can test it here.

(;-) TP

Thanks - here it is.  Just copy the text and paste as the button script...

It runs ok here from a button on V.067.

Where you getting any error codes or was it that the code just did not run at all ?

(;-) TP

presumably because of delays between the probe signal being asserted and the software actually seeing it.

Hi John

Are you using the parallel port or an external motion controller?

FWIW with the parallel port at least, Mach stores the EXACT position of the trip REGARDLESS of axis speed. It's able to do this because it both reads AND acts on inputs at/within kernel speed. Specifically - in a G31 it sends a step pulse, reads the input and if it's active it stores the position all in the time WELL before it THEN sends the next step pulse (which of course is the first step pulse of the deceleration phase (if any)). EVEN in a system that is capable of the MAX kernel speed where probing is done at MAX velocity this is STILL the case (of course your deceleration had better be damn good ). I can't comment for external motion controllers behaviour.

Ian

TP, thanks for trying my script.  My OP described the behaviour and error.  I think I need to try increasing the amount by which it lifts before the second try.

Ian, useful comment, I am using the parallel port.  Nevertheless, quicker feeds do seem to affect the accuracy when I try them, and I think I have seen other posts saying the same.

John.

Ian, useful comment, I am using the parallel port.  Nevertheless, quicker feeds do seem to affect the accuracy when I try them, and I think I have seen other posts saying the same.

Indeed - my comment was in reply to your presumption as to WHY.

Anyway - to your code... There are a few potential gotchas in there that may be causing issues. The first one is that you make no use of the first contact test. Perhaps worse is that the first contact test result can drop through to the second test.

Also your use of goto is badly structured (as goto invariably is) in that you jump out of an if clause - this can cause all sorts of hard to track bugs. I suggest you loose the label and the goto and use a repeat loop and sign the plege that you'll never use goto or labels again.
 

Ian

Thanks Ian.  I am but a barrack-room programmer I fear, my colleagues at work would laugh at me if they saw my code.  I'm an RF engineer at heart...

Actually the if... label construct was there from the version that I started with and I don't think really that it's needed.  It is just so that if you start with the probe too high and it doesn't have enough programmed movement to meet the plate the code tells you and gives you a chance to try again - but it won't help!  I will remove it.  I think I can remove one of the "contact tests" (the first one).

If not response time, why should probing precision depend on feed rate?

Thanks for your help,

John.