What's new
What's new

How do you change the overshoot distance on Brother probing macros?

DavidScott

Diamond
Joined
Jul 11, 2012
Location
Washington
I have the O0700 probing macros that came with my Brother for a Renishaw spindle probe. I know they are set in the initial program but they seem to have a minimum overshoot of .5" and I need to reduce that for a part I am making. I just don't have the room for so much overshoot probing the outside box in X and Y on this part because of the clamps. Parts are good for .001" positional before probing so I am looking for around .1"-.2" or so of overshoot.

Here is the basic part and I don't know if posting the 8700 program would be cool with Yamazen so am refraining.

G65P8700 S2. W54. Y.05 Z-.4

I have tried negative #s for Y but like I said it only shortens it up so much. I figured I would try here before bothering Greg with an email. I need to have an answer by the morning, hopefully.

If nothing else I can call out a smaller part but am interested in shortening the overshoot.

On a side note, how do you best probe for these shapes in production? I need to probe every part since I am adding the locating dowel holes in this op. I have heard others say they hit each side rotating around a circle keeping the probe on for speed and would love to know how to do it, but am a total novice at macros. Any help is appreciated.

Vise-Ends.jpg
 
Last edited:
Add an R value (Rnn.nnn) in your G65 line. The default safety distance is 10mm.
Thank you for that. I read through the Spindle Probe Operations & Cycles PDF from Yamazen and didn't catch that.

When I was getting my 4 hours of training on this machine, and the first time I have had a probe or toolsetter, I was told that the X or Y values controlled what R controls. After reading the PDF I understand that this is incorrect.
 
Ask for the Blum Quickstart manual, it has a bit more detail than the Yamazen version. I had a copy printed at OfficeDepot and keep it at my desk for quick reference.

If this is production then you can write out the routine longhand instead of posting from CAM.
Are you just finding center from the 4 outside faces, or do you need to be centered based on the slot? Are you worried about the part being at an odd angle?
Probe each side as a single axis touch as you move around the 4 sides (ex., Y-, X+, Y+, X-) and save the output values to some macro variables as you go along, then use the recorded values to find your center. Probing using single points allows you to drive straight to where you want to probe, none of the back-and-forth from center stuff. The caveat is you have to know that nothing is in your way and safely plot the course between points, the back-and-forth motions are a generic way to avoid obstacles.
M1 turns the probe on, M3 keeps it on and M2 turns it off. Turn it on with M1 as soon as you perform your probe tool change, add M3s to all your intermediate touch lines and an M2 to the last one to turn it off before you swap to your first cutter.
 
The X and Y values on an inside or outside width tell it which side to start on. An X+ will start on one side, an X- will start on the opposite side. The value is of no importance for these specific cycles.
 
I think you are using my post? Assuming yes then we keep the probe on for multiple moves already

Also as I know you like everything to be at warp speeds I would recommend moving to Blum V4r005 macros. I've made one change to them as supplied by Blum to eliminate a 0.4s delay. With these macros there are no unnecessary delays at turn on/off. You likely need a bit of support to do the upgrade, but it's not so tricky
 
Actually you can also set the overshoot in Fusion within each operation.

If it's useful, it's not so hard to have it probe part rotation and do a G68 to bring it into alignment?
 
Are you just finding center from the 4 outside faces, or do you need to be centered based on the slot? Are you worried about the part being at an odd angle?
The 4 outside faces so I have to offset to one side to avoid the slots.
Probe each side as a single axis touch as you move around the 4 sides (ex., Y-, X+, Y+, X-) and save the output values to some macro variables as you go along, then use the recorded values to find your center. Probing using single points allows you to drive straight to where you want to probe, none of the back-and-forth from center stuff. The caveat is you have to know that nothing is in your way and safely plot the course between points, the back-and-forth motions are a generic way to avoid obstacles.
M1 turns the probe on, M3 keeps it on and M2 turns it off. Turn it on with M1 as soon as you perform your probe tool change, add M3s to all your intermediate touch lines and an M2 to the last one to turn it off before you swap to your first cutter.
Thank you. Any chance I could see an example of this if you have any on hand? To be honest I don't know much about macros. This is the first time I need to probe parts in production so am a little flat footed and see a real savings in cycle time possible here.
 
I think you are using my post? Assuming yes then we keep the probe on for multiple moves already

Also as I know you like everything to be at warp speeds I would recommend moving to Blum V4r005 macros. I've made one change to them as supplied by Blum to eliminate a 0.4s delay. With these macros there are no unnecessary delays at turn on/off. You likely need a bit of support to do the upgrade, but it's not so tricky
I have your post but use mine as we do like different code. What do you mean by support? A pdf or having someone do it?

Do I need these updated macros to use your post?
 
I replied by email. Broadly it's just that the config file split into 2 pieces. One piece is now generic and the other is per-probe. So V4 macros make it simpler to support multiple probes with different config
 
You are overthinking it, drive the probe around just like any other tool from point to point. You can move it around in a protected mode where it will alarm out if it runs into anything on accident, but that only works at slow speeds (slow for a Speedio anyways). If you want to haul ass you can just use G0 moves.

You only need to use the G65 P8700 X/Y for your discrete touches. If you want to use G68 as Hi-Fly-Cnc mentioned you could add a second touch along the longest edge before moving on to your next side (4+1 touches). You can then trig out the angle from those two individual touches rather than running the entire angle setting cycle and adding 2 extra touches to your routine that also have a slow return to center (4+2).

As each cycle is run you can save the probe macro outputs to variables of your choosing or write to different WCSs (I usually write to extended WCS because its faster for me to pull up the pages of coordinates than the macros table), then do the math: #XWCS= [#X1 + #X2] / 2, #YWCS= [#Y1 + #Y2] / 2, etc...
 
Just to add to that great response:

You can set the "protected feeds" as fast as you machine can handle. So you can set it to the same as rapid move speed if you like. In my opinion no need to go to G0, keep it in G31

Also if you are writing macros by hand then you can probe one point, then there is a function to probe a second point and get an angle. You don't need to repeat the first point probe.

That said. I think a couple of repeat point probe moves will cost you less than a second if you are running the protected move at a decent clip.

Silly example. Latest Blum macros are quite a bit faster than this and you could turn up the feed speeds by at least double:

 
You can set the "protected feeds" as fast as you machine can handle. So you can set it to the same as rapid move speed if you like. In my opinion no need to go to G0, keep it in G31
Does the protected move save your probe stylus if you're traversing a part in G31 at Speedio rapid pace and accidentally clip a bolt head?
I know on our Haas VFs it doesn't even at 5% rapid :rolleyes5:
 
Does the protected move save your probe stylus if you're traversing a part in G31 at Speedio rapid pace and accidentally clip a bolt head?
I know on our Haas VFs it doesn't even at 5% rapid :rolleyes5:
Is it even protected in G0?
 
So, that's a good question. If I do the maths, then my Speedio *should* be able to stop in 1mm from 10,000mm/min speeds, even on the slowest axis. However, if I do a "G31 F5000", then it's stopped after 5mm... Something is not up to specification here...

I need to do a few more tests, because it seems like if the machine knows that the end of the move is shorter, then it stops more quickly. Phrased another way (in mm): "G91 G31 Z-10 F5000" will stop at say Z-5. But "G91 G31 Z-3 F5000" will stop at something more like Z-3

I've not done enough testing to say conclusively, but it feels like the machine can decelerate pretty fast if it wants to. It just chooses to coast to a halt on a G31 touch... uff.

So if you do a move in any axis that will not overshoot by more than 4mm in Z (depth of spring inside probe) or 5-7mm ish in XY (point the probe runs out of travel), then you can hit that point at F30000 (1200ipm) and it stops just fine!! I've tried this, built some walls with 123 blocks and deliberately crashed it repeatedly. Not an issue. However, I then assumed that meant it WOULD ALWAYS stop OK from that speed and promptly broke a bunch of probe tips, the only difference being I was setting Z-4 instead of Z-3 in Fusion. It smashed into the same surface from the same distance, and it took me a little while to understand what was happening.

Just to head off some ideas. The Speedio will accelerate exceedingly rapidly. I've done some tests to see how close you can position the probe to an object before it can't accelerate to speed. The answer is "very close", fractions of a mm. I see the machine display showing feeds of 10000 while it repositions across a 2mm wide slot on one part! So I don't think its that it cannot accelerate fast enough, it just doesn't want to...

So I'm looking to modify my Blum macros to run different max feeds in Z vs XY. Safe speeds seem to be 4000mm/min in Z and perhaps more in XY. Also, I will generally set the speeds much higher for "safe moves" around the part, since I'll run the program with the feed knob down initially. So my main risk in production is the stabbing downwards in Z. If I position the part incorrectly, or the stock is longer than expected, then it's the Z stab down that will bust the probe tip. So I kind of want that move slow and the rest are generally ok at high speed (of course there are corner cases)

I'll report back once I investigate a bit more (if anyone is interested?)
 
Is it even protected in G0?
@hi-fly-cnc suggested changing the protected moves to run at the same speed as rapids, my point was at that speed physics are not on your side and even being in "protected mode" will not save your probe so why bother.
Keep protected moves slow for when you need to run in protected mode (like onsie-twosie stuff) and rapid when you know where everything is and can safely avoid it.
 
I'm not totally in agreement here actually?

If we assume that the probe stylus is your "crumple zone", then you have a fair bit of safety barrier before you smack the probe in a Z move, assuming you are running in G31.

So my preference/argument would be for speeds somewhat proportional to the risk of a smack and also the consequences. Also, I don't know if you follow the Brother Facebook group, but I wrote up an experiment there in modifying the post to use G0 (50k) for the adaptive clearing repositioning moves, which would otherwise run at 20k. This actually slowed things down my quite a lot...!! So we need to keep in mind that G0 moves are absolute stops and a blended set of feed moves can be quite a lot faster as the machine can avoid the complete stop between them.

So assuming you add one of those "probe saver" things, my current opinion is that: previously, I would rapid "relatively close" and then G31 feed move around the part. Now I feel it faster/safer to G31 high speed feed move much closer to the part, then slow G31 feed move around the part. The saving in time by being able to get closer to the part at a higher speed more than makes up for the lack of using G0 (in my opinion). There are quite a few ways that you get saved as well, for example I can definitely say that you can G31 at very high speeds right into the part and still save the probe (I tried it deliberately), it just depends on the amount of overtravel programmed. Also, I feel that the risks are different at different points in the probe cycle. So assuming we ran the program once safely, then the failure mode on run 2 is more likely to be a part offset in X/Y, than say a WCS being miles off. So the high risk part is the stab down in Z just before doing some measurement, hence run the XY repositioning at higher speeds than the Z move, etc. Obviously nothing is impossible, but in terms of managing risks, this seems like a fair way to prioritise the highest risks?

Another idea I'm exploring is to have the post emit high(er) speed feed moves with an optional block on that line, then do a G0 move straight after. That way you can blk skip the feed moves on the second run and have the feed moves for the first run, etc.
 
I wouldn't want to scrap a stylus either... $50 for a new tip, half hour of my time to get it running again, and however much lost production due to the machine waiting.
Good point about rapids not always being faster, I should have left my assumptions at the door!
Feed moves are also nice because you could avoid any sort of dogleg but I'm not sure if that really applies on a Speedio...
How fast have to tested the skip cycle?
 
Tips are £100 here... $120 ish... I scrapped 3 in quick succession before I figured out that G31 trip is a "lethargic deceleration". Something like: I tested it repeatedly without trouble at very high speeds (like 30,000 mm/min), but with the over-travel set below the point the probe would break. As soon as I messed up on a real job the over-travel was set further (something like the stock was where I was expecting to plunge to start my XY probing). Left the tips embedded in the stock... grr

So at that point I decided I didn't want any rapid moves and started reprogramming the post to emit "safe" moves. The goal is to minimise the damage, factoring in the probability. So we do a high speed initial position with G31 on, rather than a G0. About the same speed, but at least worst case you lose the stylus, not the whole probe. Slow it down for moving near the stock. Ideally I would then like a much slower Z move to the XY move (since your over-travel before breakage is higher in the XY plane in general).

On my machine (old C00 control), I see micron repeatability on probing at 1,000mm/min touch speeds. So I can sit there all day having it touch something and it reads the same digits on the control to the micron. I'm reasonably satisfied that it's fairly "accurate" and not just repeatable, because if I do an inside probe (in XY) on a calibrated ring, then immediately after do an outside probe (in XY) on a decent quality gauge block, the numbers are within 1-3 microns of the expected sizes written on the gauge blocks (expecting the difference to be explained by the accuracy of the ball screws, size of the probe tip ruby and backlash - plus the accuracy of the gauge blocks is specified at 1-2 microns, so...). However, it repeats to the same numbers on the encoders, I'm just saying I don't know how accurate it is

At 2,000mm/min, I see the micron digit flicker between 2 values. So that's half a 10,000th of an inch variation. Blum claim their devices can measure to 0.3 microns at 2000mm/min, so I think what we are seeing here is the lack of time resolution on the C00 control? I wonder if the D00 control does better?

I think many will still be happy with that! (Especially if you have the machine in inches, because you can only see whole 10,000ths of an inch on the display - unless you paid the extra for the sub-micron feature. Basically if you run the machine in metric, you get an extra 1/5th of a digit in precision on the display for no extra cost! 😉).

There are pretty large cycle time improvements to be had by optimising the probe move speeds. Even without the stuff above, just optimising the turn on/off that we do in the post I maintain has reportedly saved one person 40+ seconds at the start of their program! I'm keen not to smash my probe, hence this research into whether we can keep ALL moves to be G31 moves while the probe is out, and also to moderate the speeds to keep all moves within the stopping distance of the machine. I do think a "probe saver" that @pat_at_old_boys popularised should be on all machines as well!
 








 
Back
Top