G53 and G54

Hi,
Not sure if this is a bug or "works as designed". In any event it was unexpected to me and undocumented and may cause some nasties.

I was testing the behaviour of G38.2 for tool probe use. What I wanted to do was something like:

G53 G38.2 Z-10

(as the tool probe location is fixed in machine coordinate terms it's natural to use that system). This is illegal, it turns out. G53 can only be used with G0 and G1. The problem was that I was in the G59.3 WCS, but after the error G54 had been made the active WCS. Naturally, being in a different WCS than you think you are is disconcerting. I also tried this with G55 in case the G59.3 is special, but same result, G54 set after the error.

In my case, no big deal as I plan to use the G59.3 WCS for tool probing. As an aside, it might be a nice feature if G38 can be used with G53, as tool probes tend to be fixed to the machine - though obviously not part probes. The change of WCS is the main issue. G54 et al are supposed to be modal, but G53 is not, so it looks like a bug to me.

Any comments?

You can set G59.3 to machine zeroNow its the same as using G53, with the benefit of only have to select G59.3 before probing.
It is normal, the machine falls back to G54 after reset or error.

I just remembered this, if using axis 2.8. My reply to subtract 1 is for 2.7.15
forum.linuxcnc.org/21-axis/38824-yes-yes...axis?start=10#164092


This copied from the manual:

Thanks for the response. Using G59.3 is exactly what I plan to do in my remapping of M6 - the documentation for G10 L11 is a huge hint! I plan to set up the G59.3 origin at the tool probe trigger point rather than home, so that tool lengths will bear some relation to the actual physical stick out from the spindle. However, the tool probe is a fixed part of the machine, so a G53 move might be considered more appropriate. Hence my test.

Back to the point at issue. You're saying that the error causes the current WCS to become G54 (#5220 is set to 1). Your quote doesn't actually back this up. It only says that if #5220 is not between 1 and 9, a 1 is written (G54). It doesn't say what happens on error. I did a couple of other tests with deliberate errors, and they also changed to G54. It then occurred to me that I had just added an ON_ABORT_COMMAND subroutine, and that includes a G54 block. Removing that causes the G53 error NOT to change the WCS, so this wound is self-inflicted. Not only is it neither a bug nor a feature, it doesn't actually happen.

My apologies to the community - still learning!

Hi nf1z,
I noticed the same behavior after an error (for which I will have to open another post). I haven't seen "ON_ABORT_COMMAND" anywhere. How did you remove it?
Thanks.

There are many mentions of it, but this might be the main one:

linuxcnc.org/docs/devel/html/remap/remap.html

Section 5.8 talks about it.

Basically, you are supposed to provide a subroutine to provide what you think you need to handle an abort for your situation. I just used the example in the docs without thinking about it, hence my problem. AFAIK, the default is no subroutine, but if you find a line in your .ini file like this

[RS274NGC]
ON_ABORT_COMMAND=O <on_abort> call

you should look and see what the <on-abort> subroutine is doing. You can remove it by removing the .ini file line (or commenting it out). Or you can edit the subroutine code to do what you really want.

Thanks nf1z,
it's not during a tool change that I have errors. I don't have ON_ABORT_COMMAND in my ini file, but I modified the on_abort file by removing the g54.
I will try again to see if this problem is solved.

Bruno