Soft limits hit after tool change

[kfmut]

Hi,

I've updated my GRBL-router setup to bCNC version from 21st of October and now from time to time I'm getting strange error after tool change. Right after I'm hitting pause button for spindle restart GRBL issues ALARM:2 error(G-code motion target exceeds machine travel) for tool's z movement:

I think it's somehow linked to stick out difference between tools because when I've lowered tool change height from -1mm to -5mm problem started to appear less frequently.

Settings for tool change:

GRBL version is 1.1g.20180614

[Harvie]

ALARM:2 error(G-code motion target exceeds machine travel)

Do you have soft limits enabled in GRBL? It seems to me that you have set them incorrectly.

And my 2nd problem:

Please do NOT create issue with two unrelated problems. Open separate issue for this and delete it from here.

[kfmut]

Do you have soft limits enabled in GRBL?

Yes, soft limits are enabled.

It seems to me that you have set them incorrectly.

Why do you think so? Last command before alarm is to move to 60.947mm in Z-axis, all machine coords on my setup are negative so maximum elevation for working coords Z would be 56.238mm(WPos Z 51.238mm + MPos 5mm)

[Harvie]

Why do you think so?

I don't know, but after all it's GRBL who is triggering the alarm. Not bCNC. There are no soft limits in bCNC. Show us your GRBL settings. You can list them by $$ command.

[kfmut]

Settings for GRBL:

$0=5
$1=255
$2=0
$3=7
$4=0
$5=1
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=1
$21=0
$22=1
$23=3
$24=25.000
$25=1000.000
$26=250
$27=1.000
$30=4729
$31=1022
$32=0
$100=133.454
$101=133.466
$102=796.812
$110=12600.000
$111=12600.000
$112=2550.000
$120=150.000
$121=150.000
$122=150.000
$130=297.000
$131=305.000
$132=85.000

I don't know, but after all it's GRBL who is triggering the alarm. Not bCNC.

But bCNC is still in tool change cycle, if I understand right bCNC corrects WCS for new tool and lifts tool so that tool's endpoint would have same elevation above workpiece as old one but app doesn't accounts for space shortness for that move. Maybe somehow possible to make this last move in machine coords, maybe some checkbox in UI for using G28-relative move?

[Harvie]

maybe just set lower safe Z?

[kfmut]

maybe just set lower safe Z?

I think in this particular example safe Z was something like 20mm above workpiece, I'll check it in few minutes...

[Harvie]

If you lower the safe Z the Z will not come so far up and thus it should not hit your soft limits. Or maybe increase the soft limits? I personaly don't use soft limits, because i don't have homing switches installed, so it does not really make sense for me. I don't need them, because i am the master of precision and i never crash the machine COUGH COUGH :-)

[kfmut]

Looks like my problem connected to G28 moves when Fusion360 clears mill head in Z direction, with "G28 G91 Z0" command.

Test program

%
(JB_vc_filtr_1)
(T2  D=1 CR=0 TAPER=118deg - ZMIN=-0.8 - drill)
G90 G94
G17
G21
G28 G91 Z0 <<<<<<<<<<<<<<<<<<<<<<<
G90

(Drill1)
M9
T2 M6
S6000 M3
G54
G0 X60 Y115.125
...

Short tool calibration cycle after probe:

G10L20P1Z1.5
ok
$G
[GC:G38.2 G54 G17 G21 G90 G94 M5 M9 T0 F25 S0]
ok
g53g0z-5.0
ok
g53g0x-285.0y-300.0
ok
g53g0x-285.0y-10.0
ok
g53g0z-45.0
ok
g91G38.2f100z-34.999
[PRB:-284.997,-10.003,-75.348:1]
ok
G38.4f100z30.433
[PRB:-284.997,-10.003,-75.336:1]
ok
g91G38.2f25.0z-4.75
[PRB:-284.997,-10.003,-75.344:1]
ok
g4p1
ok
g53g0z-5.0
ok
g53g0x-285.0y-300.0
ok
g90
ok
Run ended
2018-11-06 13:50:54.928001
Current: 19 [19]  Completed: 100% [32s Tot: 32s ]

My moves:

G91G0X50Y50
ok
$G
[GC:G0 G54 G17 G21 G91 G94 M5 M9 T0 F25 S0]
ok
G90
ok
G91G0Z-50
ok
G90
ok
G91G0X50Y50
ok
G90
ok
G90
ok

Actual program start with tool change to longer one:

G90G94
ok
G17
ok
G21
ok
G28G91Z0
ok
G90
ok
M9
ok
$g 
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F25 S0]
ok
m5 <<<<<<<<<<<<<<<<<<<<<<< tool change cycle start
ok
g53g0z-5.0
ok
g53g0x-285.0y-300.0
ok
m0
ok
g53g0x-285.0y-10.0
ok
g53g0z-45.0
ok
g91G38.2f100z-34.999
[PRB:-284.997,-10.003,-63.281:1]
ok
G38.4f100z18.366
[PRB:-284.997,-10.003,-63.281:1]
ok
g91G38.2f25.0z-16.799
[PRB:-284.997,-10.003,-63.293:1]
ok
g10l20p1z-7.353
ok
g53g0z-5.0
ok
g53g0x-285.0y-300.0
ok
m0
ok
g90
ok
g0x0.0y68.003
ok
g0z67.009
ALARM:2

[MSG:Reset to continue]

So when I change short tool to longer one, and difference is more than tool change height in bCNC router is hitting soft limits.

[Harvie]

So is this still a bCNC bug? Or it's just incompatible combination of Fusion 360 settings and GRBL settings? If Fusion 360 handles the toolchage, it probably should not be handled by bCNC otherwise you will get the offset twice and hit your softlimits.

[kfmut]

If Fusion 360 handles the toolchage

Nope, it doesn't.

So is this still a bCNC bug? Or it's just incompatible combination of Fusion 360 settings and GRBL settings?

Yep, it's incompatible combination of settings and bad luck :-) Maybe it could be handled with G28-moves but as your pointed out not everyone has limit switches and homing enabled.

I think you could close this issue. Thank you!

[Harvie]

OK. I would be happy to fix this. But if fusion decides to go beyond soft limits that you've set in grbl, i don't know how to fix this in bCNC...

[kfmut]

But if fusion decides to go beyond soft limits

No, it's bit more complicated.

It's starts with that fact that you can set your work zero in Z-axis at machine table so your tool is beneath workpiece. When you forget to lift your tool above workpiece and hit start button machine will make XY-move into workpiece, obviously breaking tool or if you are lucky enough just ram into workpiece. To handle this behavior GRBL post processor for Fusion360 has option called something like "G28 Safe retracts". G28 is like safe position of machine defined in machine coordinates( some information on that https://discuss.inventables.com/t/learning-about-g28/12205 , https://www.youtube.com/watch?v=SbxdQOVNdRY ) and it's can be used by CAM-software without knowing any specific information about any particular machine. As "safe position" G28 has no physical space to move up in Z-direction. G28-relative moves are used as a first move in program to deal with described above situation and before tool change commands.

Let's assume that MPos Z=0 is upmost physical position of machine, so all other Z-coordinates are negative.

Work Zero: MPos Z=-50
G28 safe position set in GRBL: MPos Z=-1 translates to WPos=49

Before M6 tool change command 'G28 G91 Z0' command is posted in program to clear router head, it moves tool to G-28 relative position, in our example it would be MPos Z=-1 and WPos Z=49. Now bCNC tool change routine/macro comes into play and it starting to be bit fogy for me. I assume bCNC remembers last WPos before M6 so return Z is 49. If our new tool is longer than old one(let say by 10mm), that difference must be compensated by MPos so WPos is the same as before. Translation for WPos is made, so last WPos Z=49 is correspondents not to MPos Z=-1 as before but to MPos Z=+9. So return moves for program resume are causing soft limits hit.

Last commands for tool change routine in bCNC is something like:

G90
G0x[LastWPosX]y[LastWPosY]
G0z[LastWPosZ]

If they could be changed to g28-moves by checking some check box in UI

G28 G91 Z0
G90
G0x[LastWPosX]y[LastWPosY]

or maybe just by removing last WPosZ move so it stays in tool change height

G90
G0x[LastWPosX]y[LastWPosY]

But I don't know how to ensure that tool isn't below Safe Z height.

Or maybe I should switch to TLO tool change routine rather than WCS change...

[Harvie]

So do you think that we should improve the tool change routine? It is certainly possible, but i don't wanna break workflow for other people, who are happy with how things are now. So we have to find something that would fit both cases.

[kfmut]

Yep, it would be great, maybe it's possible just to add new policy to drop down menu at "Probe->Tool->Manual Tool change->Policy" so this wouldn't affect other people immediately? Or maybe it's possible to bring some more people to this discussion to find some suitable solution?

[gregose]

@kfmut thanks for investigation and awesome explanation of Fusion 360’s G28 handling and how it causes out of limit moves when used with bCNC’s WCS tool change routine. I just ran into this myself and glad to see I’m not alone.

Did you find a work around for this?

@Harvie, I wonder if this issue warrants to be reopened to track future enhancements to the tool change routine to handle this or at least provide an explaination on what is going on in this situation?

[kfmut]

Did you find a work around for this?

Yep, it's simple as lowering G28 position in Z-direction, I think previously it was something like -1mm, now it's -10mm. But this workaround relays on fact that almost all of my tools are roughly same lenght and those 10mm of extra space is sufficient. And I'm still running my setup on version of bCNC from last November, so maybe something changed since that time.

[gregose]

@kfmut thanks. Today I tried out some changes (master...gregose:g28-toolchange) to support Fusion moving to G28 prior to the tool change. All this branch does is return Z to G28 after the tool change instead of to the stored WCS coordinates. Since this move is machine relative, the WCS modification shouldn’t cause out of limit moves.

Also in this branch is a modification to skip the first tool change. The tool change seemed unnecceeay for my workflow, since the first tool is what I use for calibration. This is an unrelated change, but I may look to extract that out as a separate option.

It also looks like there has been some good work to restore TLO after reset, which in the end might make the WCS-based tool change less useful.

[Harvie]

@gregose I don't use G28, so i don't have G28 coordinates set. Isn't this gonna crash my machine?? lines.append("g28 g91 z0")

Also what is the point of disabling these?

		#lines.append("f[feed] [spindle]")# ... feed and spindle
		#lines.append("g4 p5")		# wait 5s for spindle to speed up

[kfmut]

@Harvie IIRC your machine doesn't have limit switches installed, so it's not homed...crash is more than possible in that case.

[Harvie]

@kfmut then i obviously can't merge such modifications... bCNC still has to support machines without limit switches... We have to figure out how to fix this problem without breaking stuff.

[kfmut]

@gregose

Also in this branch is a modification to skip the first tool change. The tool change seemed unnecceeay for my workflow, since the first tool is what I use for calibration. This is an unrelated change, but I may look to extract that out as a separate option.

I don't think that skipping first M6 is good practice. For example I'm often mill PCB's and auto-level feature in bCNC is essential for that, I try to use some other tool for probing because 50+ touchdowns allows too many chances for some stupid error :-)

[kfmut]

@Harvie Yes, you are absolutely right. As I've mentioned earlier separate toolchange policy could be possible solution for that, but it's beyond my skills...

[BernardG]

This thread is a little bit old, but I just read it now. I am using Fusion 360, with bCNC, and manual tool change. THERE ARE NO REASONS G28 interfere with tool changes. To me, it just means that you never setup your G28 position properly. It's not Fusion, or GRBL, of bCNC which determine WHERE is G28. It's YOU, the user.....

G28 is NOT a relative position, but is an absolute (Machine) position, and is NOT changed by the tools probing routines/cycles.

The reasoning made by @kfmut is incorrect, for this very reason: G28 is a MACHINE pos.

http://www.linuxcnc.org/docs/2.5/html/gcode/gcode.html#sec:G28-G28_1

[kfmut]

@BernardG sorry to say that, but you've misuderstood that bCNC is using MPos coordinates during tool change all the time, it's actually using WPos coordinates for tool return. I've made my best explaining it in this message #1029 (comment)

[MARIOBASZ]

sorry if what I write is silly, I have not read the entirety carefully.
Maybe the problem is related to #1076: Using G53 with autolevel is dangerous, and the error is generated because after autolevel there are the lines for g53

[kfmut]

@MARIOBASZ I don't think that this problems are connected.

[BernardG]

@BernardG sorry to say that, but you've misuderstood that bCNC is using MPos coordinates during tool change all the time, it's actually using WPos coordinates for tool return. I've made my best explaining it in this message #1029 (comment)

I did re-read #1029 (comment) and, to me, you make unverified assumptions in there. I'll check if I can look at bCNC code, to be sure.

I mostly disagree with your affirmation that, somehow, tool change would modify MPos, and in fact, you basically say so yourself: "Or maybe I should switch to TLO tool change routine rather than WCS change..." which means that, the way you are using tool change, modify WPOS (Z0), NOT MPOS!

And the way to avoid this, is suggested by yourself (TLO)!

[BernardG]

sorry if what I write is silly, I have not read the entirety carefully.
Maybe the problem is related to #1076: Using G53 with autolevel is dangerous, and the error is generated because after autolevel there are the lines for g53

I don't think it has anything to do with using g53, as g53 is made to MOVE to absolute coordinates, but it does NOT change any offset.

http://www.linuxcnc.org/docs/html/gcode/g-code.html#gcode:g53

No, I believe it is just a misunderstanding about how bCNC tool change work:

• if you WANT tool change to modify your Z Wpos, use "Manual Tool Change (WCS)", which would be the process if your probe sit on the Work piece
• if you DO NOT WANT tool change to modify your Z Wpos, use "Manual Tool Change (TLO) which would be the process if your probe is in a fixed position on your machine, independantly from the Work Piece.

[BernardG]

sorry if what I write is silly, I have not read the entirety carefully.
Maybe the problem is related to #1076: Using G53 with autolevel is dangerous, and the error is generated because after autolevel there are the lines for g53

I don't think it has anything to do with using g53, as g53 is made to MOVE to absolute coordinates, but it does NOT change any offset.

http://www.linuxcnc.org/docs/html/gcode/g-code.html#gcode:g53

No, I believe it is just a misunderstanding about how bCNC tool change work:

• if you WANT tool change to modify your Z Wpos, use "Manual Tool Change (WCS)", which would be the process if your probe sit on the Work piece
• if you DO NOT WANT tool change to modify your Z Wpos, use "Manual Tool Change (TLO) which would be the process if your probe is in a fixed position on your machine, independently from the Work Piece.

It's pretty obvious that, if you set up your tool probe to be 20 mm BELOW the top of your work piece, and you allow tool change to modify WPos Z0, you are going to crash your tool into the work piece! But that does not means, in any way, that Mpos changed.... It means YOU used the wrong process to setup your work piece and/or your tool probe.

[kfmut]

@BernardG I really don't understand what you are trying to prove here. Tomas isn't changing source code or anything, so no worries.

[BernardG]

@BernardG I really don't understand what you are trying to prove here. Tomas isn't changing source code or anything, so no worries.

Not trying to prove anything, just trying to make sure I do understand properly how it works, which is far from certain! :-)

[DeanRM]

Interesting read - No where does anybody mention the proper setup for tool changes. There are two soft limits involved - GRBL's Z and tooldistance. Both will throw a soft limit error.
I wrote a paper on this - https://github.com/vlachoudis/bCNC/wiki/Installing-a-fixed-Touchplate-for-tool-changes

[kfmut]

@DeanRM

You have forgot key ingredient aka selecting right tool change strategy ;-) TLO is straight road to hell because GRBL is not saving it during resets and it's done after every job IIRC. Also some debounce circuitry is MUST for toolprobe. Many cheap DC spindles have they bearings placed in rubber socks so no electric contact between motor shaft and motor casing.

Proper(like really proper) setup is difficult, time-consuming and starts right from tuning feeds and acceleration which in itself requires repeatable and accurate homing.