Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Analias 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
-
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
-
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.
-
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 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.
-
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".
[mc.ISIG_PROBE] = function (state)
if machState ~= 202 then
mc.mcCntlEnable(inst, 0)
end
end
DazTheGas
-
Thanks Daz, I will look at that when I get home tonight.
-
Yup, if its fast enough that should work too Daz.
-
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
-
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
-
I still think it needs to be implemented in the motion hardware. If I remember right this is the only solution for Mach3 users. I have the same question at the Warp9D forum and Daz replied there also. I still asked Andy if it's possible to implement on the ESS. At the very least throw an E-Stop if the probe is detected during a non-G31x movement. Something more graceful would be nice, but I'm not in the know on how to implement that.
Daz's solution may help when the feeds are slower, how many hobbyist CNC are running at the high end of the feed rates?
-
Hi,
you may recall:
I think the answer is yes but it will be insufficient to protect your probe.
The reason being that Mach has communications delays that make it probable that probe damage would occur before the controller/Mach/controller loop
could act.
The ESS cannot at this time to be programmed at board level, ie realtime. Andy from Warp9 has indicated a wish to release an API for the ESS which might well
allow you to do a high speed probe protection function. When that will be available is anyones guess. Andy is commonly so involved with customer support that
development goes out the window.
PoKeys boards have as standard a board level programming feature. Whether it has the capacity to do this I don't know.
Vital Systems Hicon boards can be activated at a cost to be programmable also.
Craig
-
Well someone had to check this out to see if it could provide viable probe protection. Protection for the single supported probe is afforded by the CSMIO with plugin 2.910, but the later version 3 plugin, which supports 4 probes, does not (as yet ) offer built in protection.
Based on Daz’s suggestion I added the following to the signal table:
[mc.ISIG_PROBE] = function (state)
-- AW Add probe protection
if ((state == 1) and (machState ~= mc.MC_STATE_MRUN_PROBE)) then
mc.mcCntlEnable(inst, 0)
end
end,
The inclusion of state in the if statement ensures that only leading edges of the signal inhibit motion. As a result, it is fully compatible with the built in probing functions of Mach4 and should work with all motion, whether initiated by jogging, MDI, Gcode or MPG.
So how does this perform in practice? Craig makes the valid point that response times may be inadequate, mainly because when the drives are disabled the machine will coast to a standstill. Such behaviour is obviously system dependednt. It may be possible with some systems to stop motion under power, thereby improving deceleration.
In my case I have an elderly converted manual Bridgeport driven by ac servos. Its rapid speed is modest at 1800mm/min. I measured the position of the vice jaws and then jogged the probe towards them at 1800mm/min until probe protection kicked in. The excess travel was pretty repeatable as follows:
X axis: 2mm
Y axis: 1.5mm
Z axis: 1mm
As my homemade probe can accept an overtravel of 3mm in Z and 6mm in X and Y, I have a safety factor of about 3:1, and conclude that this is an entirely viable method of protection which I shall continue to use.
Allan
-
Hi Allan,
kool, good post.
Craig
-
As my homemade probe can accept an overtravel of 3mm in Z and 6mm in X and Y, I have a safety factor of about 3:1, and conclude that this is an entirely viable method of protection which I shall continue to use.
Allan
Most excellent, Allan.