Machsupport Forum
Mach Discussion => VB and the development of wizards => Topic started by: JohnHaine on March 02, 2013, 12:18:47 PM
-
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 ;D). 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.
;D
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.
-
If not response time, why should probing precision depend on feed rate?
You're the hardware guy - you tell me ;D
The presumption you offered is one I've heard before but as I've said is not one I agree with. This is how I satisfied myself long ago that it's not the case.
Take a microcontroller dev board (PIC, ATMEL whatever you like) and program it to count a number of interrupts on the pin of your choice. Connect the axis step pin from Mach to that interrupt pin. I set it to count an arbitrary 50,000 step pulses but it doesn't matter. When it hits that 50,000 count, program it to activate an output pin connected to the probe in pin of Mach.
Now send the axis to 0, reset the microcontroller, then do a G31 Z(whatever) that takes it to a position BEYOND 50,000 step pulses on YOUR system. Have the gcode var monitor open looking at var 2002. If all is set up correctly you'll see a value in 2002 that is the trip point and represents the distance YOUR system travels for 50,000 step pulses. Now repeat at your leisure at ANY feedrate you like. The value in 2002 will ALWAYS be the same and as I've said will be the distance Mach traveled when it tripped.
I hope you'll agree this models a probe that trips at the exact same position every time and thus takes out of the equation any mechanical issues. It also proves that Mach's ability to read the probe trip AND store that position is INDEPENDANT of feedrate.
Cheers
Ian
-
OK, well the mystery is beyond me for the moment!
As for my macro, I have removed the "goto label" horror as the feature didn't seem to be needed anyway and done some other tidying up. It now basically works as a macro called from G code or the MDI. Pasting the code as button code still didn't work UNLESS it was single stepped, in which case it worked perfectly. Maybe there is a timing issue when running CB code from a button? So I tried an alternative approach, and wrote one line of button code that called the macro (correctly this time!) and now it works perfectly from the button too.
Now to write some edge-finding macros to zero the X and Y axes...
Thanks for yoyr help,
John.