Hello Guest it is August 11, 2020, 12:12:23 AM

Author Topic: Stop on probe signal for G0/G1 moves to protect probes...  (Read 1613 times)

0 Members and 1 Guest are viewing this topic.

Stop on probe signal for G0/G1 moves to protect probes...
« on: March 16, 2018, 01:04:52 AM »
I once asked if this was possible for Mach3. I was told the engine did not support it. Now that I'm using Mach4 more I'd like to ask the same question.

I use the MachStdMill style master tool probing and touch offs. In MSM a master tool could be designated with a tool number. I am trying to replicate the same style probing that MSM supported in my own custom screen set, but would like to overcome one of the weakness of the method or my bad habits. Often the Master Tool stays in the spindle. I use it to touch off and check distances and tolerances. This means I frequently jog or do a G0/G1 from the MDI to move around. No surprised I have gone through my share of probe tips when flubbing a jog or movement.

Is it possible to have any axis movement come to a halt if any of the G31 probe signals becomes active? I realize this is a crutch, but I have moved up to a more expensive probe and the ceramic tips are going to bankrupt me if I keep doing this.

-Freeman
« Last Edit: March 16, 2018, 01:08:58 AM by Analias »
I'm not a complete idiot...
    there are some parts missing.
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #1 on: March 16, 2018, 02:01:44 AM »
Hi,
I think the answer is yes but it will be insufficient to protect your probe.

When Mach executes a G31 move it is the motion controller which monitors the probe signal and stops the axis movements the moment it does. If you wish to
have Mach monitor the probe input then there will be a delay of many milliseconds before the motion controller can signal Mach an event has occurred. Even
now that Mach is aware of a probe event it now has to abort the remainder of the jog move it has already committed to the motion controller and the controller
is executing. The current move must complete before Mach can seize control.

Note that this is different to a G31 move in that the motion controller aborts the remainder of the probe move immediately  and then reports back to Mach the position where
the abort occurred.

This behavior is because Windows and therefore Mach is not a realtime system. The delays in communication mean that there are a number of time critical motion
processes that the controller must enact because Mach can't.

As you may be aware some controllers, PoKeys boards as standard and Vital Systems boards as a paid extra feature, have the ability to program directly on the board
which IS realtime. Thus with either of those boards you could program them to do as you wish but you would have to involve yourself in some fairly low level
programming none of which has anything to do with Mach or Lua and may therefore be little support for such an effort.

I should point out that Galil is the motion control granddaddy of them all. With their boards you can program robotics and all sorts. They are famous for it and the company
has very good support for controller level programming, downside is that even one of their cheapest three axes boards are in excess of $2000. Beyond most hobbyists means
but if you have a complex realtime motion control problem Galil is the hardware you reach for and to hell with the cost.

Craig
My wife left with my best friend...
     and I miss him!

Offline Chaoticone

*
  • *
  •  5,628 5,628
  • Precision Chaos
    • View Profile
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #2 on: March 16, 2018, 05:51:38 AM »
Another way to do it is to have your probe moves do a small retract to insure the probe isn't active after probing is complete. Then from that point use probe (G31, 31.1, etc.) moves in place of G0 and G1 moves to get from point to point. This will protect your probe as well as the motion device being used can in all cases. This is how I did it in the TouchOff module. To protect the probe I use probe moves as much as possible while probing. Which means pretty much all the time. The only move that can't be a probe move is the retract because at that point the probe is active. But you also already now where you came from and at what point the touch occurred. So you also know how much you can retract and in what direction to insure the probe shouldn't be active.
;D If you could see the things I have in my head, you would be laughing too. ;D

My guard dog is not what you need to worry about!
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #3 on: March 16, 2018, 10:57:24 AM »
I'm thinking more of the case where I have finished a probing operation, and I go to jog or do a G0/G1 movement from the MDI. I'm trying to protect the probe from my stupidity; hard I know.

I just posted to Warp9D's forum asking if the ESS has such a setting. Hopefully it does.
I'm not a complete idiot...
    there are some parts missing.

Offline Chaoticone

*
  • *
  •  5,628 5,628
  • Precision Chaos
    • View Profile
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #4 on: March 16, 2018, 03:13:25 PM »
Quote
I'm thinking more of the case where I have finished a probing operation, and I go to jog or do a G0/G1 movement from the MDI

Yes, so was I.

G1 F100 X3 Vs. G31 F100 X3

or

G0 X3 Vs. G31 F10000 X3

Not a lot of difference in what you enter into MDI but the probe protection is inherently built in or it does not exist........... unless of course the hardware does some obscure form of probe protection internally. If the hardware does it internally I would want it to be a user settable option. If not it could limit the ability of users running that hardware.
;D If you could see the things I have in my head, you would be laughing too. ;D

My guard dog is not what you need to worry about!

Offline DazTheGas

*
  •  752 752
  • DazTheGas
    • View Profile
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #5 on: March 16, 2018, 05:31:41 PM »
When probing from the MDI or from a GCodeExecute command Mach4 has a state of MRUN_PROBE (202) so you could do what you want from the SigLib,  "if probe is active and the controller state is not MRUN_PROBE then disable machine".

Code: [Select]
[mc.ISIG_PROBE] = function (state)
if machState ~= 202 then
mc.mcCntlEnable(inst, 0)
end
end

DazTheGas
Theres always time for a choccy biccy
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #6 on: March 16, 2018, 05:38:16 PM »
Thanks Daz, I will look at that when I get home tonight.
I'm not a complete idiot...
    there are some parts missing.

Offline Chaoticone

*
  • *
  •  5,628 5,628
  • Precision Chaos
    • View Profile
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #7 on: March 16, 2018, 05:43:29 PM »
Yup, if its fast enough that should work too Daz.
;D If you could see the things I have in my head, you would be laughing too. ;D

My guard dog is not what you need to worry about!
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #8 on: March 16, 2018, 06:10:08 PM »
Hi,
that's the thousand dollar question.

If I understand correctly Mach responds very quickly to a signal event. How long however does it take for the Dis-able signal to reach the motion controller
and actually stop motion.

Additionally how long does the probe signal detected by the controller board take to propagate back to Mach as ISIG_PROBE?

Craig
My wife left with my best friend...
     and I miss him!
Re: Stop on probe signal for G0/G1 moves to protect probes...
« Reply #9 on: March 16, 2018, 06:15:17 PM »
Hi,
does anyone have any guesses as to how a motion controller would handle a dis-able signal in the middle of a move?

Would it coast to a stop or would it decelerate at max?

Craig
My wife left with my best friend...
     and I miss him!