This is representative of the kind of code; not much to see. The Z drive needs to withdraw until it trips a switch that currently activates input#1. When that happens, I want the Z drive to stop moving, and the next line of code to execute; the one that names the resultant z position as 0. Z works like a syringe driver; it withdraws fully (-40000 is a 'fake' position guaranteed to make the axis go far enough to trip input#1 switch regardless of where it starts from,) and moves to X151 to pick up a tube of paint.

( 4.nc  11/04/2014 18:06:54)
G21
G90
G64
G00 A0.2 F2500
( TOOL CHANGE :  4 )
M06 T4
G00 Z-40000
G92 Z0
G00 X151...

G00 X0 Y0
M06 T1
M30

It only does this at the beginning and end of each file, when it picks up/drops off a new tube of paint to paint with. There is some flexibility built into the physical structure of this axis; if it overruns a bit, no harm, but currently it overruns by about 5-6mm sometimes, which is pushing it.

Having just spoken to the manufacturer of my drivers, I may be able to simply use a 'normally closed' switch in series with the lead that runs from the breakout board to the driver, which when tripped by the z axis movement will switch off the step signal to the Z drive, causing the motor to stop. May try this before investigating software solutions, will post something soon.

AH OK . You need to rethink your Gcode approach.  Simply have the Z refhome to the switch (G28.1 Z0.000) . It will raise until it hits the switch THEN reset the Z to Zero as you do in the Gcode ( G92 Z0.000).

That way you have full control of Z all the time.  We use the same approach with Plasma machines only we are looking for the top of the material.

IF it were ME I would do it in a Macro (Zrefhome) that way you could still use run from here if needed. Otherwise in straight Gcode Run from here will not work with a G28.1 call in the code.

(;-) TP

Ah, I forgot to say, my Z needs to home in the opposite direction. I hadn't thought to include this information, sorry. The whole reason for this is to keep my Z homing in the positive direction, while this other homing like behaviour goes in the opposite direction. Mach doesn't allow 2 homing directions for the same axis...

Cutting the step signal to the driver works, but when I send the step signal through the 18feet of wire it takes to go from the BOB through the (previously input#1) switch to the driver, the step signal is too weak to trigger any behaviour in the driver it seems. Very annoying that is, as it worked brilliantly with just 4ft of wire. I suppose I could rig something up with an external supply and a relay, but I'd rather not.

So, will putting something like the original script into 'brains' give me a quicker response than using macropump? If it could , problem (maybe) solved.

Brains seems to only allow me to have one button push as an end result. Not helpful, as I want to

1001 'feedhold
252 'switch off Z axis
1021 'reset
1021 'reset again
252 'switch z axis back on again

Can an OEM trigger make this run in macro form when the switch (currently input#1) activates?

It seems like it ought to in principle, but heres nothing in the manual for making oem triggers start a macro. Can anyone guide me to that information?

try to read something about G31

I have, but it seemed to do the same as G28.1, unless I did something wrong.

Is it possible to use G31 in the opposite direction to the homing direction for an axis? I thought it wasn't, but the manual makes no mention of that, so I'm not sure what led me to that conclusion.

G31 gives you only a exact Information where the Input was hit (Basic idea of probing).
post your code how you tried to use it.
Thomas

I would if I could! It was probably at least 6 months ago, and would have been on the old pc that died. I'll try configuring my switch as 'probe' tomorrow, and try a G31 command to see if it works. The description in the manual sounds like the sort of behaviour that I need it to have. Thanks for the suggestion.