Problem using BitZero XYZ probe procedure

I cannot use the Standard Block XYZ probe procedure because my touch plate has a hole in it where the Standard Block requires the bit to be positioned for the initial Z probe, so I am trying to use the BitZero procedure. I position the bit ( a 1/4 steel dowel in this case) close to the center of the hole in the touch plate and lower it about 1/4" below the top of the plate. The procedure works as expected, touching X in two positions and Y in two positions to find the center of the hole and then the bit moves up and over away from the hole to do the Z probe. All seems well until I position the bit to XYZ zero. The X zero looks right on, but the Y zero is off by about 1/8” and the Z zero is off by 2-3 mm. There’s not not much to the setup in config, just the plate thickness, so I don’t understand why this is happening.

If I watch the process, when it makes the X probes it come to the center of the hole before making the Y probes, but when it makes the Y probes it does not come back to center. It seems to be off by about 1/2 the tool diameter, so maybe this is a math error in the routine. I have no idea why the Z is off so much.

Is anyone using this procedure with success? Am I missing something in the setup?

The bit zero routine is meant to be used with specifically the bit zero touch plate, not any touchplate with a hole.

You’d need to have a custom probe macro with your specific touchplate dimensions.

I’d recommend grabbing the bitzero macro and and adjust it for your specific plate geometry.

You’d need to add the distance from the center of the hole to the edge to the X+Y zero via the probe_x_offset and probe_y_offset variables.

That looks like it would work for my touch plate with just adjusting the plate thickness and bore diameter. The center of the hole in my touch plate is exactly over the corner of the workpiece where XY zero should be, so no X or Y offset is needed. I don’t have any experience with Gsender, so I’ll look at how to import the macro this evening and hopefully I can test it tomorrow.

I got a chance to test this macro today and it looks like there is a bug in it. It does set Z zero ok, but both the X and Y zeros are off by what looks like ½ the tool diameter (1/4”). X is off by 1/8 in the –X direction and Y is off by 1/8 in the +Y direction. When watching the probe process, once it probes the two X positions, it is supposed to move to the center of the hole on the X axis, but it clearly does not. Same thing happens with the Y probe. I’ve looked at the equations in the macro and on the surface they look correct, but I’m not familiar with some of the syntax in the macro, so maybe someone with more experience with the language can look at this and figure out what is going on. The only modifications I made to the original macro was to set PROBE_INSET_THICKNESS = 15 and PROBE_BORE_DIAMETER = 20 to match my probe plate dimensions.

@davebmck Dave: What version of gSender are you using? I seem to recall that there was a bug fix introduced a couple of versions ago that dealt with an issue of the XY0 being off by 1/2 the diameter of the bit used.

i’m using version 1.6.3

@davebmck Maybe this is required too?

No, the center of the hole in my plate is directly over the XY zero point, so no X or Y offset should be required.

@davebmck Yeah, sorry, I just saw that in your second post.

Did you confirm that it moves by half the bit diameter by testing with two bit of different diameters? Or does it move by ±1/8" regardless of bit size?

No, I’ve just tested with the 1/4 dowel. The bit diameter isn’t used in the macro and this is another reason it’s so curious that the position is off by half the bit diameter. Can anyone direct me to a source where I can learn more about the syntax used in these macros?

I’ve been looking through the macro documentation on Sienci and more on the CNCjs site and I think I get most of the syntax now. One exception is the macro I’ve been trying to get to work uses the expression X1= Number (posx), whereas all of the other probing macros I’ve seen just use X1= posx. What is the function of the Number parameter and does it return a different value? I doubt this is the source of the problem, I’d just like to know what the reason is to use one expression vs the other.

The main difference I see in this macro vs the other hole probing macros I’ve seen is that this one takes the two probed positions X1 and X2 and adds them together and divides by 2 to get the center position. It then uses an absolute positioning move to put the bit in that location. The other macros just find the incremental difference between X1 and X2 and divide that by 2. Then they use an incremental move to position the bit to the center position. This is clearly where the macro is failing because if you watch it run, the bit does not move to the center of the hole.

Both of these techniques look mathematically correct so I don’t understand why the one in this macro is not working. Since posx and posy return positions in the G54 work space, depending on where the WCS was previously set, both values could be positive or negative or one could be positive and the other negative. I haven’t had a chance to work through all the combinations yet, but I’m wondering if this is screwing up the math in some cases.

Number is just the Javascript function, which ensures the value is numerical before it’s used in any calculations, otherwise you run the risk of things like addition acting as concatenation.

The math in the macros is fine, it’s been available for years in some form without issue. It’s likely some other issue - maybe unit related or possibly mechanical with steps/mm

What units are you probing in (g20/g21)? Do you have $13 (report in inches) enabled and if so do you get different results if it’s off.

Thanks for the info on the Number function.

I have checked the positioning accuracy of my machine over the full X axis range (about 24”) and it’s as close as I can measure it, so I think I can rule out steps/mm. I usually run mostly in inches, but this macro sets G21 at the start, so I should be probing in mm. I’m traveling until Friday, so when I get home I will look at $13 and test both settings. Looks like it should be set to 0 for this macro to work correctly.

You’re right about the math. I sat down this afternoon and tried every potential variation for X1 and X2 with real numbers and the calculation works every time. When I get back home I’m going to run each line of the macro at the console one by one and check the result. I should be able to see what’s happening then.

I got back to my shop today and before I started testing I decided to rerun the macro as a reference. And you probably guessed it, the macro worked perfectly. I have no idea why it didn’t work last time I tried it. Its the same setup as before, no changes, only the machine and program were restarted after being off for a week.

I guess the good side of this exercise is that I learned a lot about programming macros in Gsender and that should benefit me going forward.

Thanks for letting us know - we’ll close this for now. Glad you got it working (even under mysterious circumcstances)