Issues using G53 or G92.2 in Tool Change Script

Post technical questions about the Buildbotic Controller here.
Forum rules
No profanity, no gambling, no illegal activity, so sexual or pornographic material.

Posts not related to the Buildbotic CNC Controller are likely to be moved or deleted.
Post Reply
bustosalex1
Posts: 7
Joined: Sun Apr 25, 2021 8:46 pm

Issues using G53 or G92.2 in Tool Change Script

Post by bustosalex1 » Mon Apr 26, 2021 5:43 pm

Hi everyone,

I've got a Buildbotics controller hooked up to my Taig mill and I'm using a toolsetter probe between tool changes to automate the process of measuring new tools for jobs with multiple tools. The probe sits at a fixed point in machine coordinates (I just bolted it to the table), so I am trying to either use G53 to move in machine coordinates or G92.2 to temporarily disable global offsets so that I can then move to the probe position in machine coordinates. For context, I do have homing switches setup on my mill. The problem I'm running into is that the Buildbotics controller does not respect G53 or G92.2, it's as if it's still trying to move in work offset coordinates. Because of this, when I have the work offset set closer to the upper limits of the axes, the controller will say that the job will move outside some axes bounds (even though it won't, since on the toolchange it will be moving in machine cooridinates), and thus I can't start the job. Has anyone else had this error and possibly know how to fix it? Thanks!

User avatar
Doug
Posts: 343
Joined: Fri Feb 02, 2018 4:56 pm

Re: Issues using G53 or G92.2 in Tool Change Script

Post by Doug » Mon Apr 26, 2021 6:22 pm

Please attach a short gcode program that provides an example of this behavior and I will try to duplicate the issue here.

Skyler
Posts: 22
Joined: Fri Oct 30, 2020 10:25 am

Re: Issues using G53 or G92.2 in Tool Change Script

Post by Skyler » Mon Apr 26, 2021 8:43 pm

Hi Alex,

I've also experienced similar issues, and I have been using what seems to be a similar tool probe setup. It seems like a lot of what are standard features on other software are not yet fully implimented in the Buildbotics controller. However, G92 works as expected.

Here are my tool change scripts. One for my DIY palletized workholding system with a fixed work offset, and one for setting a work offset with the normal buttons in the UI. For the pallet one, I use the axis configuration to have my work origin in the X and Y coincide with the absolute X0 Y0 position. I have several different configuration files saved for switching between different types of jobs. Hopefully these make some sense and help you.




Pallet Probing


#<_workoffset> = -3.672
#<_masterprobe> = -2.053
#<_nexttoolprobe> = 0


M70
M5 (stop spindle)
G53 G0 Z#5163 (go to Z home)
G92 Z0 (clear G92 offset)
G53 G0 X1 Y-1.3 (move to probe switch position)

(probe next tool)
o101 if [#<_selected_tool> EQ 0]
M0 M6 (MSG, INSERT TOOL 0)

o101 elseif [#<_selected_tool> EQ 1]
M0 M6 (MSG, INSERT TOOL 1)

o101 elseif [#<_selected_tool> EQ 12]
M0 M6 (MSG, INSERT TOOL 12)

o101 elseif [#<_selected_tool> EQ 17]
M0 M6 (MSG, INSERT TOOL 17)

o101 elseif [#<_selected_tool> EQ 18]
M0 M6 (MSG, INSERT TOOL 18)

o101 elseif [#<_selected_tool> EQ 19]
M0 M6 (MSG, INSERT TOOL 19)

o101 elseif [#<_selected_tool> EQ 21]
M0 M6 (MSG, INSERT TOOL 21)

o101 elseif [#<_selected_tool> EQ 22]
M0 M6 (MSG, INSERT TOOL 22)

o101 else
M0 M6 (MSG, INSERT NEXT TOOL)

o101 endif



G38.2 Z-6.5 F10 (probe next tool)
#<_nexttoolprobe> = #5063 (save probe result)
G53 G0 Z#5163 (go to Z home)

(set new G92)
G92 Z-[#<_workoffset> - [#<_masterprobe> - #<_nexttoolprobe>]] (adjust G92 for tool length)

M0(MSG, TURN SPINDLE ON)

M72














Standard


Program Start:

#<_last tool> = 0
#<_next tool> = 0

Tool Change:

M5 (stop spindle)
#<_original offset> = #5213 (save current G92 offset)
G53 G0 Z#5163 (go to Z home)
G90 (absolute distance mode)
G92 Z0 (clear G92 offset)
G53 G0 X8 Y0 (move to probe switch position)

o100 if [#<_last tool> EQ 0]
(probe last tool)
G38.2 Z-6.5 F10 (probe last tool)
#<_last tool> = #5063 (save probe result)
G53 G0 Z#5163 (go to Z home)

(probe next tool)
o101 if [#<_selected_tool> EQ 0]
M0 M6 (MSG, INSERT TOOL 0)

o101 elseif [#<_selected_tool> EQ 1]
M0 M6 (MSG, INSERT TOOL 1)

o101 elseif [#<_selected_tool> EQ 12]
M0 M6 (MSG, INSERT TOOL 12)

o101 elseif [#<_selected_tool> EQ 17]
M0 M6 (MSG, INSERT TOOL 17)

o101 elseif [#<_selected_tool> EQ 18]
M0 M6 (MSG, INSERT TOOL 18)

o101 elseif [#<_selected_tool> EQ 19]
M0 M6 (MSG, INSERT TOOL 19)

o101 elseif [#<_selected_tool> EQ 21]
M0 M6 (MSG, INSERT TOOL 21)

o101 elseif [#<_selected_tool> EQ 22]
M0 M6 (MSG, INSERT TOOL 22)

o101 else
M0 M6 (MSG, INSERT NEXT TOOL)

o101 endif

G38.2 Z-6.5 F10 (probe next tool)
#<_next tool> = #5063 (save probe result)
G53 G0 Z#5163 (go to Z home)

(set new G92)
G92 Z-[#<_original offset> - [#<_last tool> - #<_next tool>]] (adjust G92 for tool length)

(update tool variables)
#<_last tool> = #<_next tool>

o100 else
(probe next tool)
o100 if [#<_last tool> EQ 0]
(probe last tool)
G38.2 Z-6.5 F10 (probe last tool)
#<_last tool> = #5063 (save probe result)
G53 G0 Z#5163 (go to Z home)

(probe next tool)
o102 if [#<_selected_tool> EQ 0]
M0 M6 (MSG, INSERT TOOL 0)

o102 elseif [#<_selected_tool> EQ 1]
M0 M6 (MSG, INSERT TOOL 1)

o102 elseif [#<_selected_tool> EQ 12]
M0 M6 (MSG, INSERT TOOL 12)

o102 elseif [#<_selected_tool> EQ 17]
M0 M6 (MSG, INSERT TOOL 17)

o102 elseif [#<_selected_tool> EQ 18]
M0 M6 (MSG, INSERT TOOL 18)

o102 elseif [#<_selected_tool> EQ 19]
M0 M6 (MSG, INSERT TOOL 19)

o102 elseif [#<_selected_tool> EQ 21]
M0 M6 (MSG, INSERT TOOL 21)

o102 elseif [#<_selected_tool> EQ 22]
M0 M6 (MSG, INSERT TOOL 22)

o102 else
M0 M6 (MSG, INSERT NEXT TOOL)

o102 endif

G38.2 Z-6.5 F10 (probe next tool)
#<_next tool> = #5063 (save probe result)
G53 G0 Z#5163 (go to Z home)

(set new G92)
G92 Z-[#<_original offset> - [#<_last tool> - #<_next tool>]] (adjust G92 for tool length)

(update tool variables)
#<_last tool> = #<_next tool>
o100 endif
M0(MSG, TURN SPINDLE ON)

XCross
Posts: 6
Joined: Sun Feb 03, 2019 5:22 am

Re: Issues using G53 or G92.2 in Tool Change Script

Post by XCross » Tue Apr 27, 2021 12:57 pm

Hi Alex,

i have the same problem.

My tool change script:

M70
G21 (metric units)
G90
G53 G0 Z160
G53 G0 X30 Y0
M0 (MSG, Change bit and attach probe)
F100
G91
G38.2 Z-160
G92 Z11.954 (calculate height -1.32)
G0 Z30
M0 (MSG, Remove Probe)
M72

It seems that the software is going to add the 160mm from the G53 and the 11.954 from the G92 to the stock height and that this value therefore exeeds the max-z-softlimit (the sum is exact the z-value from the bounds in the 3D-View). The only work around it to increase the (negative) min-z-softlimit, so that the absolute value |max-z - min-z| ist larger than the calculated value.

Is it me or the software?

Thanks

bustosalex1
Posts: 7
Joined: Sun Apr 25, 2021 8:46 pm

Re: Issues using G53 or G92.2 in Tool Change Script

Post by bustosalex1 » Sat May 01, 2021 1:11 pm

Hi Doug, Skyler, and XCross,

Thanks for your responses! Doug, my tool change script is attached below, along with a simple program utilizing a tool change. As you can see, in the Buildbotics web app, my G92 offsets in this example are set to X: 212.302mm, Y: 74.531mm, Z: 65.052mm. My probe is located in machine coordinates at X: 0mm, Y: 85.8mm, and I park the tool at Z: 85mm in machine coordinates for some clearance above the probe to change tools.
The example program I’ve provided simply faces off a 25mm x 25mm square block, changes tools, and then uses a different tool to trace out a 12.7mm diameter circle within the stock. For context, my axes limits are set to X: 270mm , Y: 135mm, Z: 150mm, so I should have plenty of Y and Z clearance for this small part. However, as you can see from the screenshot of the Buildbotics DRO, it says I’m going over my Y and Z limits due to the toolchange. And, in the visualization, you can see that instead of moving to X: 0mm, Y: 85.8mm in machine coordinates, it is moving to these coordinates with the G92 offsets applied. Thanks for your help and please let me know if you need any additional clarification.

In response to Skyler, thanks for providing your toolchange script! I will have to see if I can replicate this on my machine.
In response to XCross, I believe we’re having the same problem, which would lead me to believe that this is a software issue and not just you.

Tool Change Script:

M70 (save current machine state)
G91 G0 Z0.1 (go up 0.1" from the current Z height)
G21 G40 G49 (switch to mm, turn off cutter compensation, cancel tool length compensation)
G17 (select XY plane)
G90 (set absolute mode)
G53 G0 Z85 F600 (move to Z = 85mm in machine coordinates)
G53 G0 X0 Y85.8 F600 (move to X = 0mm, Y = 85.8mm in machine coordinates, this is the XY position of the probe)
M0(MSG, Click 'Continue' after stopping spindle.)
G91 (set incremental distance mode)
G38.2 Z-50 F250 (probe current tool)
G0 Z1 F300 (move to 1mm above the current height)
G38.2 Z-4 F8 (reprobe)
G90 (switch to absolute distance mode)
#5000=#<_z> (store the current z height in variable #5000)
M0(DEBUG, Current Endmill Length Probe Height: #5000 mm)
G53 G0 X0 Y85.8 Z85 F600 (move to 0, 85.8, 85 mm in machine coordinates)

M0(MSG, Change tool and attach tool probe.)
G91 (switch to incremental distance mode)
G38.2 Z-50 F250 (probe new tool)
G0 Z1 F300 (move 1 mm above current height)
G38.2 Z-4 F8 (reprobe)
G90 (switch to absolute distance mode)
#4999 = #<_z> (store current z height in variable #4999)
M0(DEBUG, New Endmill Length Probe Height: #4999 mm)
G92 Z[#5000]
M0(DEBUG, Old Z-Axis Height: #4999; New Z-Axis Height: #<_z>)
G91
G0 Z25 F300
G90
M0(MSG, Turn on spindle.)
M72

Buildbotics CAM Visualizer:
visualization.PNG
Buildbotics DRO:
dro.PNG
Attachments
toolchange_example.nc
(1.34 KiB) Downloaded 230 times
toolchange_example.nc
(1.34 KiB) Downloaded 225 times
visualization.PNG
toolchange_example.nc
(1.34 KiB) Downloaded 240 times
visualization.PNG

User avatar
Doug
Posts: 343
Joined: Fri Feb 02, 2018 4:56 pm

Re: Issues using G53 or G92.2 in Tool Change Script

Post by Doug » Sun May 02, 2021 11:56 am

I reduced the program to this:

Code: Select all

G90 G94 (Absolute distance mode; Feed in units per minute)
G17 (using XY plane)
G21

G53 G0 Z85 F600
G53 G0 X0 Y85.8

M30
%
This took the tool change out of the picture and just executes the G53 commands. Sure enough, this cause the Y and Z lines in the axis table to turn yellow and display 'OVER'. However, when I actually run the program, it seems to complete correctly.

I also tried this same program in the new V1.0.0 software that we are about to release. The result was the same.

I also tried the G92.2 command as suggested like this:

Code: Select all

G90 G94 (Absolute distance mode; Feed in units per minute)
G17 (using XY plane)
G21

G92.2
G0 Z85
G0 X0 Y85.3
G92.3

M30
I got the same result.

My assessment is that G53 and G92.2 offset changes are not handled correctly in the simulation, however they work correctly when executed either in the tool-change or in the main program.

If you agree with this assessment, I will submit a new issue in our github tracker. Hopefully, we can get if fixed in V1.0.1.

What do you think?

bustosalex1
Posts: 7
Joined: Sun Apr 25, 2021 8:46 pm

Re: Issues using G53 or G92.2 in Tool Change Script

Post by bustosalex1 » Sun May 02, 2021 12:51 pm

Hi Doug,

Thanks for the response. Yes, that's exactly correct. The G92 offsets are not handled correctly in the simulation, but when running the job (for jobs that fit within the simulation's incorrect interpretation of offsets) they work properly, so I would say that you're good to go ahead and submit an issue ticket. I appreciate your help with this issue and I look forward to v1.0.1!

User avatar
Doug
Posts: 343
Joined: Fri Feb 02, 2018 4:56 pm

Re: Issues using G53 or G92.2 in Tool Change Script

Post by Doug » Sun May 02, 2021 7:25 pm

I submitted a bug report in our github repository. See https://github.com/buildbotics/bbctrl-f ... issues/297

I cannot say for certain that it will be fixed in V1.0.1. At least the issue is documented.

Thank you for bringing the issue to our attention.

Post Reply